wafer.space Community - open.cob.json: One File Between the Chip...

5:29 a.m.

This looks great @Stephan Bökelmann! I wonder if anybody can try running their chip designs through this to see how it works and help us? Looking at you @Essen @Leo Moser (mole99) @RebelMike @ReJ aka Renaldas Zioma (and of course everybody else

)

1

5:32 a.m.

@Tim 'mithro' Ansell FYI

@kris - We should certainly get this in some type of write up.

..... Actually..... how is the "oh so manual" interface to the wire bonder anyways? "Botting" TUIs and GUIs is far from a new thing... If there's any storage media import/export for bond configurations that are normally very manually keyed in to the machine we could see about at least covering the happy path of work with automation; I'm assuming the interactive mode has some sort of single stepping that'd allow visual confirmation of no tool head movements into unacceptable positions and then confirmation it's doing the bonding in an acceptable fashion? @stuart perhaps try to grab such config files during next opportunity, for bond jobs that we could run through this kind of automation tooling such as open.cob.json and let some AI agent work out the file format and then match it's "G-code" (or w/e) to the json?

namibj

..... Actually..... how is the "oh so manual" interface to the wire bonder anyways? "Botting" TUIs and GUIs is far from a new thing... If there's any storage media import/export for bond configurations that are normally very manually keyed in to the machine we could see about at least covering the happy path of work with automation; I'm assuming the interactive mode has some sort of single stepping that'd allow visual confirmation of no tool head movements into unacceptable positions and then confirmation it's doing the bonding in an acceptable fashion? @stuart perhaps try to grab such config files during next opportunity, for bond jobs that we could run through this kind of automation tooling such as open.cob.json and let some AI agent work out the file format and then match it's "G-code" (or w/e) to the json?

this is a pretty good idea, thanks for the suggestion! @Stephan Bökelmann I know you know this pain

If the plan is to intercept a serial or such terminal connection from a frontend to the brain, I'd see about sniffing that and video recording the screen to go with it. Might be fairly easy to do. Also keyboard emulation (especially with some state feedback to keep it from veering off into doing stupid things) can do wonders without notably interrupting the usability in normal ways.

@namibj - Keyboard emulation and a vga or hdmi capture device can definitely go a long way.

Very nice @Stephan Bökelmann, looking forwards to giving this a spin in the coming days.

1

@Tim Edwards - As "owner" of Magic, it probably makes sense for you to be involved / offer opinions here.

namibj

..... Actually..... how is the "oh so manual" interface to the wire bonder anyways? "Botting" TUIs and GUIs is far from a new thing... If there's any storage media import/export for bond configurations that are normally very manually keyed in to the machine we could see about at least covering the happy path of work with automation; I'm assuming the interactive mode has some sort of single stepping that'd allow visual confirmation of no tool head movements into unacceptable positions and then confirmation it's doing the bonding in an acceptable fashion? @stuart perhaps try to grab such config files during next opportunity, for bond jobs that we could run through this kind of automation tooling such as open.cob.json and let some AI agent work out the file format and then match it's "G-code" (or w/e) to the json?

One thing that I tried was letting claude figuring out the configuration for my FK delvotek bonder. Wasn't the best I've seen so far. I guess one of the problems with bonders is, that they don't just take G-code. Hopefully some day in the near future there will be an open-wirebonder project that just accepts g-code like every printer does. In that case, coming from the open.cob to g-code is maybe a week of work with python. In the open.cob, there is a section for wire definitions. I have also played around with a python tool to generate these for me from my specifications, but that hasn't worked out completely yet. especially if you want to support all sorts of different loop-forms. I attached a picture of my bonder and ONE of its 3 menues to manage the loop shapes. Unfortunately every bonder that I've worked with so far handles loop-forms differently.

1

Stephan Bökelmann

One thing that I tried was letting claude figuring out the configuration for my FK delvotek bonder. Wasn't the best I've seen so far. I guess one of the problems with bonders is, that they don't just take G-code. Hopefully some day in the near future there will be an open-wirebonder project that just accepts g-code like every printer does. In that case, coming from the open.cob to g-code is maybe a week of work with python. In the open.cob, there is a section for wire definitions. I have also played around with a python tool to generate these for me from my specifications, but that hasn't worked out completely yet. especially if you want to support all sorts of different loop-forms. I attached a picture of my bonder and ONE of its 3 menues to manage the loop shapes. Unfortunately every bonder that I've worked with so far handles loop-forms differently.

I mean, yeah, they may not take G-code, but they do take something.

2:20 p.m.

Note that loop shape isn't so much the most important here

2:20 p.m.

different tool heads will change what that should be

namibj

I mean, yeah, they may not take G-code, but they do take something.

agree

namibj

Note that loop shape isn't so much the most important here

disagree

IMO the giant part is being able to support diffferent pinouts to different COB layouts with negligible extra engineering time need

2:20 p.m.

(for wafer.space)

namibj

IMO the giant part is being able to support diffferent pinouts to different COB layouts with negligible extra engineering time need

yeah. I mean, if it's okay to have pins in all directions and they have enough pitch, chip has the same top metallization, wire is always the same and so forth. you can set up the loop form once and it will work. Maybe I focus too much on my own use-case

I'd assume a resin printed or laser sintered COB panel carrier to hold and align the bundles of COBs to be fairly straight forward especially if given to the PCB designer as a template it has to conform to while taking care to properly hug the PCB; then the big part of specifying where the bonding shall go.

1

Stephan Bökelmann

One thing that I tried was letting claude figuring out the configuration for my FK delvotek bonder. Wasn't the best I've seen so far. I guess one of the problems with bonders is, that they don't just take G-code. Hopefully some day in the near future there will be an open-wirebonder project that just accepts g-code like every printer does. In that case, coming from the open.cob to g-code is maybe a week of work with python. In the open.cob, there is a section for wire definitions. I have also played around with a python tool to generate these for me from my specifications, but that hasn't worked out completely yet. especially if you want to support all sorts of different loop-forms. I attached a picture of my bonder and ONE of its 3 menues to manage the loop shapes. Unfortunately every bonder that I've worked with so far handles loop-forms differently.

can you show when you have a chance what S-Wire is? By chance?

namibj

can you show when you have a chance what S-Wire is? By chance?

Generally speaking, an S-loop is a wire-bond loop profile with a longer, relatively flat mid-section between the rise after the first bond and the descent to the second bond. It is used when the span is long, when loop height must stay controlled, when the wire needs extra stiffness against mold sweep, or when clearance over neighboring structures is required. I just left the lab, but I can take a picture of the menu in the next couple of days and post it.

ohhh I see I think

sometimes I use that setup when I want to get down as soon as possible and put other wires above it

2:27 p.m.

let me search a picture

I thought it might be about more free-form specification like splines or so

I think here I used S-form for the first row.

2:28 p.m.

my glueing looks really messy

2:29 p.m.

I'm hoping we might figure out a way to at least precision align dies to the board so that doesn't meaningfully widen the bond pads....

innermost row is s-shape IIRC

I think I can tell the S shape form

namibj

I'm hoping we might figure out a way to at least precision align dies to the board so that doesn't meaningfully widen the bond pads....

hmm I don't think I understand. can you elaborate?

so one major reason for the large fan out currently is that we don't know the alignment of the die to the PCB traces with enough precision

2:31 p.m.

therefore, we need fairly large PCB side landing pads for the bonds

2:31 p.m.

(much larger than the PCB litho feature size it would reliably offer)

2:32 p.m.

this causes much longer bonds than would be needed otuwise due to limited bond density on the PCB side

2:32 p.m.

2:33 p.m.

Notably, compare the bond pad landing site size to how narrow the escape tracks at the bottom are

2:34 p.m.

The PCB litho could do almost double the density if the alignment would be better

2:34 p.m.

So that the bonds hit both the PCB and the die pads without much widening needed to account for the psoitioning error of the bond movement vs. the pad itself

2:35 p.m.

(this happens from the bonding being referenced optically to the die AFAIK, not to the PCB)

okay, i see. Who places the die and how? Which type of glue is used and how much? Is that specified or does the bonding-company just do whatever they think is correct?

2:41 p.m.

I have placed a lot of dies by hand (which is super annoying) or with this tool: https://elas.hu/en/product/manual-and-semi-automatic-pick-and-place/ I think placing it with +/- 25µm accuracy is possible. what happend to me a couple of times is, that if I added too much glue on the bottom, the chip would drift while the glue hardens

FRITSCH Manual & semi-automatic placers

FRITSCH manual and semi-automatic pick-and-place systems enable the complete assembly process—from component feeding to the placement of various chips, SO, and FP components.

Stephan Bökelmann

okay, i see. Who places the die and how? Which type of glue is used and how much? Is that specified or does the bonding-company just do whatever they think is correct?

Currently it just happens at the bonding co; but I see no inherent issue with not having that be this outsourced.

11:04 p.m.

I wonder if there's no pressure sensitive adhesive suitable for the task; e.g. if I think of the ACF tape that's essentially epoxy prepreg but with no fibers only some loading of nickel spheres that are designed to crush into adjacent surfaces on localized compression letting the rest squeeze out slightly sideways from the pads. It's heat activated within 10 seconds; but AFAIK it's tacky enough near-instantly. Like, with that knowledge, I'm confident there's sticky tape or even just using some process that attaches a tacky sheet to the back of the die that can then be placed and pressed briefly before applying hardening. Or, say, one of the heat activated epoxy types for a few seconds. Or even just having something that can just lay over the area and keep both from sliding away from another, like e.g. just a strip of very soft silicone mat placed across the die being rubbery non-slip against the PCB and the die. Of course if only we had more free automation of the bonder it could pick up optical alignment from the die and the PCB and just use die coordinates for die bond sites and PCB coordinates for PCB bond sites.

@stuart / @Lauri / @Andrew Wingate - Lots of things from @namibj & @Stephan Bökelmann that might be worth commenting on or discussing?

1:33 a.m.

@psychogenic - Just wanted to make sure you saw this thread. As mentioned in the past, I would love to figure out a way to have you do a YouTube video tutorial once KiCAD support is landed.

Tim 'mithro' Ansell

@psychogenic - Just wanted to make sure you saw this thread. As mentioned in the past, I would love to figure out a way to have you do a YouTube video tutorial once KiCAD support is landed.

I hadn't, thanks for the ping. I might be able to assist with the plugin side--been meaning to update https://github.com/psychogenic/kicad-skip and think it could be of use here. In any case, just did a design using the GF CoB and could certainly give this all a go to see how things stand.

Tim 'mithro' Ansell

@stuart / @Lauri / @Andrew Wingate - Lots of things from @namibj & @Stephan Bökelmann that might be worth commenting on or discussing?

I have been watching, but haven't had the time to internalize it all yet. Please someone correct me if I'm wrong, but here's how I'm reading this so far. We have:

die [pad locations]
CoB [pad locations]
stretch goal [define wire shape?] We want: Description Language json, yaml, w/e Generated from:
.kicad_pcb
GDS Is there even enough info there?
Not sure about wire shape
Placement and Orientation inferred from GDS/KiCad

Current pad definitions are located in slot_size.yaml in the template, defined by N/S/W/E I used that truth to sync kicad and gds from my original wirebonding drawing maker. Sorry, I don't think I have too much to add other than saying 'start at first principles' and whatever comes from this should be an exchange format others can parse for their needs, ie. pnp, wirebonder, etc. Does that sound right?

Only somewhat connected to what Andrew said above -- I was thinking about it from what type of software might need / use the stuff found in the file and came up with the following items:

(a) Python script which generates a nice looking PDF (designed for a human) which can be given to a bond house technician to do the bonding in a manual fashion.

(b) Some type of "rules based" DRC checking software which tries to validate if a plan is manufacturable.

(c) Some type of "simulation based" DRC checking software which runs a 3d simulation of the bonding head flying over a virtual model of the design and checks for things like clearance between the bond head and other objects.

(d) Some type of "bond machine programming" software which loads the data into a wire bonding machine in some way (probably initually using nasty emulated keyboard and screen capture type stuff)

(e) Some type of "bond testing / validation" software / board like what @Lauri has developed for wafer.space

I was also thinking there probably needs to be renders of the GDS included so that visual alignment / correction can be done? Ideally this could all work without needing special alignment marks on the part?

1

Afaik we also want to be able to define how the chip can be electrically tested after bonding. Also render of the die for the bonding diagram

1

Andrew Wingate

I have been watching, but haven't had the time to internalize it all yet. Please someone correct me if I'm wrong, but here's how I'm reading this so far. We have:

die [pad locations]
CoB [pad locations]
stretch goal [define wire shape?] We want: Description Language json, yaml, w/e Generated from:
.kicad_pcb
GDS Is there even enough info there?
Not sure about wire shape
Placement and Orientation inferred from GDS/KiCad

Current pad definitions are located in slot_size.yaml in the template, defined by N/S/W/E I used that truth to sync kicad and gds from my original wirebonding drawing maker. Sorry, I don't think I have too much to add other than saying 'start at first principles' and whatever comes from this should be an exchange format others can parse for their needs, ie. pnp, wirebonder, etc. Does that sound right?

Not generated from the PCB files, but generated FOR the PCB. The Die is the source of truth for it's own size and pad placement. From there you can generate "rule based" landingpatterns for the PCB Layout, which also gives you the symbol. The loop-length/shape can be generated from the landingpattern, the die height and pad-placement. Additional parameters for the loops can be generated by inspecting the kicad-netlist + the dies pad-definitions + rules. With a completely filled .cob.json, you can automatically generate bonding program and electrical tests. These give you the source of truth for all further simulation.

Stephan Bökelmann

Not generated from the PCB files, but generated FOR the PCB. The Die is the source of truth for it's own size and pad placement. From there you can generate "rule based" landingpatterns for the PCB Layout, which also gives you the symbol. The loop-length/shape can be generated from the landingpattern, the die height and pad-placement. Additional parameters for the loops can be generated by inspecting the kicad-netlist + the dies pad-definitions + rules. With a completely filled .cob.json, you can automatically generate bonding program and electrical tests. These give you the source of truth for all further simulation.

Ok, I think this sounds about right. But again, The Die is GDS?? I think this is enough to get (a), (b), (c) from @Tim 'mithro' Ansell list. (a) may be partial as it's only the kicad symbol? Current iterations hold vss and vdd more or less constant.

the dies pad-definitions

This is still the part that is tripping me up. I don't think any of this is accessible from GDS. Someone correct me if I'm wrong, but this gates (d) potential patterning and other data still missing. (e) what testing even means for a given pin/pad is still undefined

7:44 a.m.

Tldr; full pcb required for full assembly diagram supplemental data required for testing scheme

Andrew Wingate

Ok, I think this sounds about right. But again, The Die is GDS?? I think this is enough to get (a), (b), (c) from @Tim 'mithro' Ansell list. (a) may be partial as it's only the kicad symbol? Current iterations hold vss and vdd more or less constant.

the dies pad-definitions

This is still the part that is tripping me up. I don't think any of this is accessible from GDS. Someone correct me if I'm wrong, but this gates (d) potential patterning and other data still missing. (e) what testing even means for a given pin/pad is still undefined

you get the pad geometries from the gds + the process parameters give you the hight of the die

1

7:45 a.m.

at least that's what I've been using for years

1

Stephan Bökelmann

you get the pad geometries from the gds + the process parameters give you the hight of the die

Yeah, I think you and I are in line here. Just trying to fit some of @Tim 'mithro' Ansell and @stuart requests are more difficult

the general idea that I implemented was: having all necessary data in one place, so I don't always have to go through a billion documents. my .cob.json file has severd this purpose so far. alle information that is needed can be either extracted from die+process, then you run the half- but well-formed file through a script, that generates the landingpattern on the pcb with some manual intervention (or automatically if you set the correct defaults). from there you can generate the wires with some manuel intervention (or automatically if you set the correct defaults). The testing specs are something that I added on @stuart s request. I don't know yet how to get them into the file the most convinient way, but it is the correct place to store the information.

7:50 a.m.

as soon as the file is fully-formed, everything else can be generated from there - at least that's what worked for me so far.

7:51 a.m.

and of course the person creating the gds can attach TEXT Records to the pads, which makes all further steps much easier

Cool @Stephan Bökelmann ! I understand I'm not helping, but maybe getting expectations in check is help

Thanks! Please ping me if you think there's a place I can help!

dang, I really want that 6DOF micro-manipulator thing that should be able to visually line up and hold in place while the die attach ceases being liquid... or just as well line die up with flip chip substrate for ACF SerDes first though. Automating "the bond diagram" at current bond diagram design rules is gonna be fine regardless of such custom hardware anyways.

Minor heads up @Stephan Bökelmann, I will be keeping notes on my usage and issues encountered so far in the issues section of the github. I will ping you again when I am done.

1

Essen

Minor heads up @Stephan Bökelmann, I will be keeping notes on my usage and issues encountered so far in the issues section of the github. I will ping you again when I am done.

Nice, Thank you!

I have a random dream of having a blender animation automatically generated from your KiCAD PCB + GDS + open.cob.json which shows the bond machine doing the bond.

2

Tim 'mithro' Ansell

I have a random dream of having a blender animation automatically generated from your KiCAD PCB + GDS + open.cob.json which shows the bond machine doing the bond.

Sounds fun. Unfortunately I have never worked with blender or something alike

I feel like this is something an AI might be good at doing, for the simple reason is that it just needs to kinda of look good and has no actual consequence if it gets it wrong and your animation has the bond head fly off to infinity or something

1

7:06 a.m.

Rendering solid simple objects like this seems much easier than the other random AI generated blender animations I see other people posting.

Can someone give me 3 different GDS or OASIS files from actual chips, that I can add to the repo publicly for testing?

10:06 a.m.

Would be great, if they had different geometrical bonding pad configurations, different hights and different outlines

https://github.com/wafer-space/ws-run1 and https://github.com/wafer-space/ws-run2 has lots of links

GitHub - wafer-space/ws-run1: wafer.space GF180MCU Run 1

wafer.space GF180MCU Run 1. Contribute to wafer-space/ws-run1 development by creating an account on GitHub.

GitHub - wafer-space/ws-run2: wafer.space GF180MCU Run 2

wafer.space GF180MCU Run 2. Contribute to wafer-space/ws-run2 development by creating an account on GitHub.

1

1:47 p.m.

There is also https://github.com/wafer-space/chip-on-board-wire-bonded-pcbs

GitHub - wafer-space/chip-on-board-wire-bonded-pcbs: Wire bonded ch...

Wire bonded chip on board PCB designs. Contribute to wafer-space/chip-on-board-wire-bonded-pcbs development by creating an account on GitHub.

Stephan Bökelmann

Can someone give me 3 different GDS or OASIS files from actual chips, that I can add to the repo publicly for testing?

I have 3 but one is an IHP cmos5l chip

I think @Andrew Wingate has some bond diagrams somewhere...

1:49 p.m.

Apparently I have some too at https://github.com/mithro/wafer-space-die-pad-diagrams

GitHub - mithro/wafer-space-die-pad-diagrams

Contribute to mithro/wafer-space-die-pad-diagrams development by creating an account on GitHub.

Tim 'mithro' Ansell

Apparently I have some too at https://github.com/mithro/wafer-space-die-pad-diagrams

That was all vibe coded, so don't expect it to be any good

Here are the few that I have. I can't remember if they ended up somewhere more useful.

wirebonding_detail.zip

4.63 MB

run1 and run2 bonding diagrams: https://github.com/szfate/ws-bonding-diagrams/tree/master/bonding-diagrams

ws-bonding-diagrams/bonding-diagrams at master · szfate/ws-bonding...

wafer.space bonding diagrams. Contribute to szfate/ws-bonding-diagrams development by creating an account on GitHub.

Oh cool! Thanks y'all. Now I don't have to worry that my weekend gets too boring

1

Stephan Bökelmann

Can someone give me 3 different GDS or OASIS files from actual chips, that I can add to the repo publicly for testing?

There's certainly the tinytapeout with different bonding from the COB default offer

I have assembled all my feeback from the past few days into a single issues : https://github.com/MaxClerkwell/open.cob.json/issues/3

Feedback on cob.json format · Issue #3 · MaxClerkwell/open.cob.json

Hi, I have been exploring the tools and the proposed cob.json file format for the past few days. Although I also have many comments on the tools, since they are still a work in progress and are not...

1

Essen

I have assembled all my feeback from the past few days into a single issues : https://github.com/MaxClerkwell/open.cob.json/issues/3

I will look into it tomorrow! Thank you kindly for your feedback!

1